Skip to content

Update mimalloc to 3.6.0 - #28068

Open
kleisauke wants to merge 10 commits into
emscripten-core:mainfrom
kleisauke:mimalloc-update-3.6.0
Open

kleisauke wants to merge 10 commits into
emscripten-core:mainfrom
kleisauke:mimalloc-update-3.6.0

Conversation

@kleisauke

Copy link
Copy Markdown
Collaborator

No description provided.

@kleisauke

kleisauke commented Oct 24, 2026 •

Copy link
Copy Markdown
Collaborator Author

This time we needed to do more than what was done previously in #28026 (comment), i.e.:

Tested with:

$ ./test/runner {core2,wasmfs,wasm64_4gb}.test_wrap_malloc_mimalloc other.test_malloc_size_mimalloc* other.test_malloc_multithreading_mimalloc* other.test_mimalloc_headers
Running 8 tests
Using 8 parallel test processes
[8/8] test_malloc_size_mimalloc_O2 (test_other.other.test_malloc_size_mimalloc_O2) ... ok

----------------------------------------------------------------------
Ran 8 tests in 1.141s

OK
Total core time: 4.017s. Wallclock time: 1.141s. Parallelization: 3.52x.

@gemini-code-assist gemini-code-assist Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code Review

This pull request updates mimalloc to version 3.6.0, introducing a major refactoring of the internal headers and source files into structured subdirectories. Key enhancements include a new pprof-compatible heap profiler, support for quiescent state-based reclamation (QSBR), better cache-line-aware allocations, improved fork support, and various bug fixes. Regarding the feedback, a potential false positive was identified in the mismatched delete operator check within free.c for small allocations with large alignments; adding a check to ensure the page does not have interior pointers would resolve this issue.

Comment thread system/lib/mimalloc/src/alloc/free.c

@sbc100 sbc100 left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@kleisauke

Copy link
Copy Markdown
Collaborator Author

Why revert microsoft/mimalloc@80d6e71 (e076497)?

I think that commit only makes sense when an application/library includes mimalloc as a dependency, not for the dedicated -sMALLOC=mimalloc setting. Also, our patchset forwards those builtins to mimalloc, so that commit won't work.

#ifdef __EMSCRIPTEN__ // emscripten adds some more on top of WASI
void* emscripten_builtin_malloc(size_t size) MI_FORWARD1(mi_malloc, size)
void* emscripten_builtin_realloc(void* p, size_t size) MI_FORWARD2(mi_realloc, p, size)
void emscripten_builtin_free(void* p) MI_FORWARD0(mi_free, p)
void* emscripten_builtin_memalign(size_t alignment, size_t size) { return mi_memalign(alignment, size); }
void* emscripten_builtin_calloc(size_t nmemb, size_t size) MI_FORWARD2(mi_calloc, nmemb, size)
#endif

FWIW, there are some design notes here explaining why mimalloc is built on top of emmalloc:

// Design
// ======
//
// mimalloc is built on top of emmalloc. emmalloc is a minimal allocator on top
// of sbrk. The reason for having three layers here is that we want mimalloc to
// be able to allocate and release system memory properly, the same way it would
// when using VirtualAlloc on Windows or mmap on POSIX, and sbrk is too limited.
// Specifically, sbrk can only go up and down, and not "skip" over regions, and
// so we end up either never freeing memory to the system, or we can get stuck
// with holes.
//
// Atm wasm generally does *not* free memory back the system: once grown, we do
// not shrink back down (https://github.com/WebAssembly/design/issues/1397).
// However, that is expected to improve
// (https://github.com/WebAssembly/memory-control/blob/main/proposals/memory-control/Overview.md)
// and so we do not want to bake those limitations in here.
//
// Even without that issue, we want our system allocator to handle holes, that
// is, it should merge freed regions and allow allocating new content there of
// the full size, etc., so that we do not waste space. That means that the
// system allocator really does need to handle the general problem of allocating
// and freeing variable-sized chunks of memory in a random order, like malloc/
// free do. And so it makes sense to layer mimalloc on top of such an
// implementation.
//
// emmalloc makes sense for the lower level because it is small and simple while
// still fully handling merging of holes etc. It is not the most efficient
// allocator, but our assumption is that mimalloc needs to be fast while the
// system allocator underneath it is called much less frequently.
//

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants